High availability for event forwarding

ABSTRACT

High availability event forwarding can be obtained utilizing distributed queues in a server cluster. Each server can receive an event from a data system, such as a database or SAP™ system. Event queues exist oil servers in the cluster can store an event until, for example, the event is delivered to a user or retrieved for processing. An event processor examines the load of each event queue and selects tie event queue with the lightest load The event processor generates an alias for the selected queue, such that a user, integration system, or client application does not need to know the identity of the physical queue storing the event, but only needs to refer to the ‘distributed queue’ or alias. After a physical queue is selected and an alias assigned, the event is forwarded to the selected queue. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.10/293,656 filed Nov. 13, 2002, entitled “HIGH AVAILABILITY FOR EVENTFORWARDING” [Atty. Docket No. BEAS-01262US1], which claims priority toU.S. Provisional Patent Application No. 60/376,960, expired, filed May1, 2002, entitled “HIGH AVAILABILITY FOR EVENT FORWARDINGN” [Atty.Docket No. BEAS-01262US0] which is hereby incorporated herein byreference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent documents contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentof the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

CROSS REFERENCED CASES

The following applications are cross-referenced and incorporated hereinby reference:

U.S. patent application Ser. No. 10/271,194, now 7,080,092, entitled“Application View Component for System Integration,” by Mitch Upton,filed Oct. 15, 2002.

U.S. patent application Ser. No. 10/293,059 entitled “High Availabilityfor Asynchronous Requests,” by Tim Potter et al., filed Nov. 13, 2002.

U.S. patent application Ser. No. 10/293,059 entitled “High AvailabilityApplication View Deployment,” by Tim Potter et al., filed Nov. 13, 2002.

U.S. patent application Ser. No. 10/293,674 entitled “High AvailabilityEvent Topic,” by Tim Potter et al., filed Nov. 13, 2002.

FIELD OF THE INVENTION

The present invention relates to the forwarding of events and messagesto a cluster or across a network.

BACKGROUND

In present application integration (AI) systems, there can be severalsingle points of failure. These single points of failure can includedeployment or management facilities event forwarding, event topics,remote clients, event subscriptions, response listeners, and responsequeues. Each of these features is tied to a singe server within a servercluster. If that single server crashes, the entire AI application canbecome irreparably damaged and must be rebooted via a server reboot.

An AI component can generate events, such as through the use ofadapters, that a user may wish to consume through a service such asbusiness process management (BPM). An event forwarding facility of apresent AI system forwards events between an application view and aphysical BPM event queue. This facility is a single point of failure aswell as a performance bottlenecks.

BRIEF SUMMARY

Systems and methods in accordance with the present invention canovercome deficiencies in prior art systems by providing for highavailability event forwarding. In a server cluster, each server canreceive an event from a data source, such as a database or SAP™ system.An event queue resides on at least one of the servers in the cluster,which is capable of storing an event. An event queue can store an eventuntil, for example, the event is delivered to a user or retrieved forprocessing.

An event processor exists on at least one of the sellers in the cluster.The event processor can examine the load of each event queue in thecluster and determine which event queue has the lightest load. The eventprocessor can generate an alias for the selected queue, such that auser, integration system, or client application, for example, can locatethe event by specifying the alias. The user does not need to know theidentity of the actual physical queue in which the event is stored, butonlv refers to the “distributed queue” or alias used to locate theactual physical queue. After the event processor selects a physicalqueue to act as the distributed queue and assigns an alias, the eventcan be forwarded to that physical queue.

Other features, aspects, and objects of the invention can be obtainedfrom a review of the specification, the figures, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system in accordance with one embodiment of thepresent invention.

FIG. 2 is flowchart for a method that can be used with the system ofFIG. 1.

DETAILED DESCRIPTION

A system and method in accordance with one embodiment of the presentinvention overcomes deficiencies in prior ant systems by, changing theway in which events are routed throughout an AI system. In presentmessaging systems, an event router which can be tightly coupled to anSAP™ system or database, can receive an event out of the SAP™ system ordatabase and send that event into an integration server. The integrationserver propagates the event out to anybody who is interested in theevent, such as anyone having registered a listener for events of thattype. Events can also be propagated to subscribers of an events topic towhich that event belongs. Event forwarding is one mechanism forpropagating these messages. In present systems, events are forwarded byan event router to a physical queue, from which interested users orclients can retrieve the events. This physical queue is a single pointof failure.

In a system in accordance with one embodiment of the present inventionevent forwarding is highly available. High availability can beaccomplished through the use of distributed queues and/or topics, Adistributed queue can server as an alias, and is not a physical queue ina specific server. A highly-available approach allows a user to send amessage to a distributed queue. A server in the cluster, such as the onereceiving the message, can determine which server in the clustercontains the physical queue with the lightest load that is online andworking properly.

After determining, which physical queue should receive the message, theserver can find that physical queue and put the message on the queue.The user can be unaware of which queue is being used, and may not care.To the user, the message is sent to the alias, or distributed queue.This system is similar to a front end, in that it allows a messagingimplementation such as JMS to be highly available, without requiringsubstantial work on the part of a client. When using a distributed eventqueue for event forwarding, it is possible to rely on the unde1rving JMSto do a lot of the high availability work.

Event forwarding in accordance with the present invention can be usedwith multiple event topics, or with a single distributed event topic. AnAI system can create a single JMS Topic for each topic subscriber.Events for a given subscriber can be sent to the topic for thesubscriber. Event delivery can also be consolidated onto a single JMSQueue, such as EVENT_QUEUE, for example. This queue can be a distributedqueue with multiple physical destinations. A message driven bean (MDB),which can be referred to as an ‘AI Event Processor’ can listen on theEVENT_QUEUE distributed destination. An onMessage implementation for theMDB can deliver a copy of the event into the BPM event processor, suchas if BPM is installed and running in the server instance.

The onMessage implementation can also publish a copy of the event ontoan event topic, or “EVENT_TOPIC.” An event topic is a distributed JMStopic that handles the delivery of events to remote application viewclients . An application view class can be modified to create an eventcontext on the event topic. The event context class can be modified tofilter messages based on the application view name, which can be storedin a “SourceKey” JMS header property.

The implementation can deliver a copy of the event into an ap1plicationview Cajun Control event processor, if such a control is being used.Also, any dequening or execution for the implementation can be donetransactionally to allow the message to be rolled back onto the queue inthe event of a processing failure

Using a queue and MDB approach allows exactly one copy of each event tobe delivered into a system such as BPM and Cajun, while still usingdistributed destinations. The use of topics would yield multiple copiesit distributed destinations were used. This approach also provides thecontinued ability to support event delivery to remote application viewclients. High availability can be obtained by virtue of the distributedEVENT_QUEUE destination. Multi servers can participate in the processingof messages for this queue, and thus a single server failure can beaccommodated.

This approach also provides for better efficiency, as events can berouted directly to a BPM event processor and application view CajunControl event processor without requeuing a copy of the message whichcan have associated persistence and delivery overhead. A secondarypublish to an EVENT_TOPIC can be somewhat costly, but the BPM eventprocessors can be processing the event before the event is sent to theevent topic, allowing more direct processing into BPM.

FIG. 1 shows a system that can be used for high-availability eventprocessing in an application integration engine. In an example of eventprocessing, an event occurs in an enterprise information system (EIS)130. The event data is transferred to an event generator 128 in theresource adapter. The event generator 128 transforms the EIS-specificevent data into an XML document and posts an event object, such as anEvent object, to the event router 126. The event router 126 passes theevent object to an event context object 124 for each AI server that isinterested in the specific event type. The event context object 124encapsulates the event object into a JMS object message and sends it tothe event queue 122, such as a JMS Queue bound at JNDI contextcom.ai.EVENT_QUEUE using a JMS QueueSender. This queue can be adistributed queue, in that the selected queue exists somewhere in thecluster but uses the same alias.

The event object message is stored in the event queue 122 until it isretrieved for processingo by the AI event processor 120, which canprocess events in a first-in-first-out 4(FIFO) manner. It may not beenough to send a message to a distributed queue and expect the messageto be received by a receiver of that distributed queue. There can be areceiver, or “QueueReceiver”, receiver or listening on each physicalqueue to which an event could be forwarded. Thus an AI event processorcan be deployed on all nodes in a cluster. Multiple event processordeployment can further prevent single points of failure.

The event processor 120 can forward the event to all registered eventdestinations 110 which in the Figure include a BPM event queue 112, anevent topic 114, and a Cajun event processor 116. Event destinations canbe added by posting a message to a notification topic 108 forapplication integration. For example, when an AI plug-in 100 for BPM isdeployed, it can send an “addDestination” message to the notificationtopic to register the BPM event queue 112 as an event destination. TheBPM event queue can be a distributed queue. A message published on thenotification topic can have cluster-wide visibility. Each node in thecluster can have a singleton event destination manager 118 that is adurable subscriber to this topic. Thus, the message can be published toevery event destination manager in the cluster.

The event processor can use a singleton event destination manager 118 tolisten for add/remove event destination messages on the notificationtopic 108 to configure the list of event destinations 110. The eventobject message can be delivered to all registered event destinations ina single transaction, such as in a single Java™ Transaction API (JYA)user transaction. If a post to any event destination 110 fails, theevent message can be rolled back to the distributed queue 122. The rollback can use the same alias, but can forward the event to a differentphysical queue in the cluster. If the event processor 120 receives amessage such as one that has “getJMSRedelivered()” true, the post can betried again. If the retry fails, the message can be sent to an errorqueue, which can be a distributed queue for failed event andasynchronous service response messages.

If an AI plug-in 100 for BPM is deployed, the plug-in can add the BPMevent queue 112 as an event destination during startup so that AI eventsare passed to a BPM workflow 102 for processing. If there are anyregistered application view event listeners 106, the event can be sentto an event topic 114 which will use event context 104 to establish aconnection with the remote event listener 106 for the application view.

FIG. 2 shows the steps of a method that can be used with the system ofFIG. 1. An event is generated in a data system, such as a database orSAP™ system 200. An event router receives the event from the data systemand forwards it to a server in the cluster 202. The server receiving theevent determines which server in the cluster contains the event queuewith the lightest load 204. The server then creates an alias for theevent queue with the lightest load, which will be used to refer to thedistributed event queue containing the event 206. The server thenforwards the event to the distributed event queue and assigns the alias208.

An event context class is a frame of reference that can be used togenerate and/or receive events. An event context class can be used by anapplication view to manage the event delivery mechanics in methods suchas postEvent and addEventListener. An application view can represent asubset of business functionality that is available, for example, withinan EIS. The application view can accept requests for service invocationfrom a client, and can invoke the proper system functions within thetarget EIS. An application view can make use of connections provided bya resource adapter to communicate with the EIS.

A service can be a named business function. An application view canmanage mapping from the name of the service to the system function inthe EIS. Services can expose a simple XML-based request and responseinterface. Services can return a document definition object for requestand response document types that describe the structure and contentrequired for the document type.

An application view can utilize metadata that includes information suchas a service name and associated system function. The metadata care alsostore at least some of the data needed to successfully invoke the systemfunction. As a result, the service can require less request data fromthe client invoking service, as the application view can augment thedata passed by the client with the stored metadata. This is a convenientway to hide the complexity of the underlying system function invocationfrom the client invoking a service.

In the event of the crash of a cluster server or managed server, an AIapplication can continue delivering events from adapters running innodes that are still available. Event generators or routers running inthe failed node can restart when the failed node restarts. Users can benotified that in-flight transactions have been cancelled or rolled-back,and should be retried. Wherever possible, the transaction can be retriedafter reestablishing connections, in order to make use of resources onanother live server One example of AI reestablishing a connection is theevent context as used for sending. events to AI from an event router.

In the event of an admin server failure, an AI application can do thetasks listed with respect to the crash of a cluster server. The AIapplication should still be able to boot and reboot successfully usingthe previous domain and server configuration.

The use of server clustering allows an AI component, such as anevent-forwarding server, event queue, or JMS server, to be used in ascalable and highly available fashion. A highly available component doesnot have any single points of failure, and can migrate services fromfailed nodes to live nodes in a cluster. Any service offered by an AIcomponent can be targeted to several nodes in a cluster. In the event ofa node failure in the cluster, the services located on the failed nodecan be migrated to another live node in the cluster.

In the event of a crash of a cluster or managed server, the AIapplication can continue accepting new work. The acceptance of new workcan include the deploying and undeploying of application views andconnection factories, monitoring of old application views and connectionfactories, delivering events from adapters, and servicing bothsynchronous and asynchronous, service invocations. An AI application canalso support the manual migration of services on the failed node to alive node, such as a singleton MDB listening on a physical destinationmanaged by a failed JMS server. Application integration can use asingleton MDB, such as if a customer needs ordered event processing.

The foregoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many modifications andvariations will be apparent to one of ordinary skill in the art. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical application, therebyenabling others skilled in the art to understand the invention forvarious embodiments and with various modifications, that are suited tothe particular use contemplated. It is intended that the scope of theinvention be defined by the following claims and their equivalence.

1. A system for high availability event forwarding in an integrationsystem comprising: a cluster of servers, each server in the clusteradapted to receive an event; event queues on at least some of theservers in said cluster of servers, the event queues adapted to storethe event; and an event processor on at least one server in said clusterof servers, the event processor adapted to determine the available eventqueue with the lightest load and forward the event to that event queue2. A system according to claim 1, wherein: the event processor furtheradapted to generate an alias for the event queue to which the event isforwarded, wherein the alias abstracts the server location of thedetermined event queue from a user.
 3. A system according to claim 1,further comprising: a data system adapted to generate an event.
 4. A.system according to claim 3, wherein: said data system is selected fromthe group consisting of databases, EIS systems, and SAP™ systems.
 5. Asystem according to claim 3, further comprising: an event router adaptedto receive the event from the data system and forward the event to thecluster of servers.
 6. A system according to claim 1, furthercomprising: a listener on at least one server in the cluster, thelistener adapted to listen for the event on each event queue in thecluster.
 7. A system according to claim 6, further comprising: alistener on each server in the cluster, each listener adapted to listenfor tile event on each eve qt queue in the cluster.
 8. A systemaccording to claim 6, wherein said listener listens for the event on theevent queue using the alias.
 9. A method for high availability eventforwarding in an integration system, comprising.: receiving an event toserver in a cluster of servers: determining which server in the clustercontains the event queue with the lightest load; and forwarding theevent to the event queue with the lightest load and assigning the aliasto that event queue
 10. A method according to claim 9, furthercomprising: creating an alias for the event queue with the lightestload, wherein the alias abstracts the server location of the determinedevent queue from a user.
 11. A method according to claim. 9, furthercomprising: generating the event with a data system.
 12. A methodaccording to claim 11 further receiving the event from the data systemto an event router and forwarding the event to the cluster of servers.13. A method according to claim 9, further comprising: listening for theevent on each event queue in the cluster using a listener on at leastone server an the cluster.
 14. A method according to claim 9, furthercomprising: listening for the event on each event queue in the clusterusing a listener on each server in the cluster.
 15. A computer programproduct for execution by a server computer for high availability eventforwarding in an integration system, comprising: computer code toreceive an event to server in a cluster of servers; computer code todetermine which server in the cluster contains the event queue with thelightest load; and computer code to forward the event to the event queuewith the lightest load and assigning the alias to that event queue 16.The computer program product of claim 15, further comprising: computercode to create an alias for the event queue with the lightest load,wherein the alias abstracts the server location of the determined eventqueue from a user.